home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / std / c++ / 879 < prev    next >
Encoding:
Internet Message Format  |  1996-08-06  |  3.0 KB
  1. From: aishdas@haven.ios.com (Micha Berger)
  2. Message-ID: <4jc1n9$dvp@news.ios.com>
  3. X-Original-Date: 27 Mar 1996 18:34:17 GMT
  4. Path: in2.uu.net!bounce-back
  5. Date: 27 Mar 96 21:39:10 GMT
  6. Approved: fjh@cs.mu.oz.au
  7. Newsgroups: comp.std.c++
  8. Subject: Re: Suggestion to the C++ standard
  9. Organization: AishDas Society
  10. References: <4jatnm$s9b@post.tau.ac.il>
  11. X-Newsreader: TIN [version 1.2 PL2]
  12. X-Auth: PGPMoose V1.1 PGP comp.std.c++
  13.     iQBFAgUBMVm1ieEDnX0m9pzZAQHFDAF/XAA1xR6jm2+e+6odPu4UB9hzHTB+o4+S
  14.     mS+IIfDNSkVhL3lkXXQjWdlXm3O9MRyx
  15.     =n0vb
  16.  
  17. Marueli Sunny (sunny@libra.math.tau.ac.il) wrote:
  18. : class foo
  19. : {
  20. : private:
  21. :     Type Member : read GetMember, write SetMember;
  22. : };
  23.  
  24. I'm not sure of the point of this syntax, but either way it would be too
  25. limiting. Something that comes up often is where the get method ought
  26. to be public, but the set method shouldn't.
  27.  
  28. So, we'd have to change the syntax to:
  29. class foo
  30. {
  31. private:
  32.       Type Member : public read GetMember, protected write SetMember;
  33. };
  34.  
  35. or, since we want to split interface (public or protected) from the internals
  36. we'd want GetMember in the public section, and SetMember in the protected
  37. section, perhaps with syntax like this:
  38. class foo  
  39. {
  40. public:
  41.     Type GetMember : read Member;
  42. protected:
  43.     void SetMember : write Member;
  44. }
  45.  
  46. Member could be either declared, or figured out as a private member of
  47. type Type. But is this really any better than
  48. class foo {
  49. public:
  50.     Type GetMember { return Member; }
  51. protected:
  52.     void SetMember(const Type& m) { Member = m; }
  53. private:
  54.     Type Member;
  55. }
  56.  
  57. BTW, I prefer using Type member() and void member(const Type&) as a naming
  58. convention for access functions. Less verbose, but just as clear.
  59.  
  60.  
  61. Perhaps a suggestion would have been to allow member v'bles to have a
  62. pair of access modifiers, and allow automatically generated access functions
  63. have each of the pair. For example
  64. class foo
  65. {
  66. public read, protected write:
  67.     Type Member;
  68. }
  69.  
  70. which automatically generates a v'ble and two access function all of the same
  71. name. The fact that the three have different manglings saves the linker from
  72. ambiguity, and the lack of prototype vs. two different prototypes clears up
  73. compiler issues.
  74. Actually, such a system could force all member variable private, always
  75. generate access functions. We could just take "public:" as shorthand for
  76. "public read, public write:", etc...
  77.  
  78. Interesting feature, won't happen.
  79.  
  80.  
  81. --
  82. Micha Berger 201 916-0287        Help free Ron Arad, held by Syria 3255 days!
  83. AishDas@haven.ios.com                     (16-Oct-86 -  5-Oct-95)
  84. <a href=news:alt.religion.aishdas>Orthodox Judaism: Torah, Avodah, Chessed</a>
  85. <a href=http://haven.ios.com/~aishdas>AishDas Society's Home Page</a>
  86. ---
  87. [ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
  88. [ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
  89. [ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
  90. [ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
  91. [ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]
  92.